Reject individual records when the mock database is over quota - #582

The second commit adds a test that fails on main. It reproduces #547.

The test drives MockCloudDatabase with ordinary writes and sends. It does not build a sync engine event by hand.

The limit in the mock

MockCloudDatabase.modifyRecords treated an over-quota batch as all or nothing. It reverted the batch and then failed every record with quotaExceeded.

The real server keeps the records that fit and rejects the other records. A child record next to a rejected parent gets referenceViolation, not quotaExceeded.

The logs on #548 show this pair of errors:

Save failed | parents  | ...:parents  | quotaExceeded (25)
Save failed | children | ...:children | referenceViolation (31)

The mock did not produce that pair. Therefore no test reached the referenceViolation branch of handleSentRecordZoneChanges with a parent that never went to the server.

saveRecordToDatabase already rejects a child when the server does not hold the parent, but that check exempts a parent that is present in recordsToSave. The exemption is correct when the save of the parent succeeds. It is wrong when that save fails, and nothing looked again.

The changes

• An over-quota batch gives the space that remains to the smallest records. It rejects the largest records with quotaExceeded.
• The mock then rejects a saved record if the server does not hold its parent. The error is referenceViolation. This step repeats until no record changes, because a rejected child orphans its own children.
• This step also runs on the normal save path. A parent can fail for other reasons than quotaExceeded.
• The mock writes saves first and rejects some of them afterwards. A rejection now puts the record back to the version the server held before the batch, so a failed update leaves the previous version in place instead of deleting the record.

The test

listAndReminderRejectedWhileStorageIsFull seeds one list (parent) with a large title and one small reminder (child). Then it sends the batch.

The list fails with quotaExceeded. The reminder fails with referenceViolation. The handler applies the ON DELETE CASCADE on reminders.remindersListID, and deletes a row that the server never held.

Two expectations then fail. Line 502 expects the reminder row on the device. Line 518 expects the reminder to reach the server after the quota rises.

This test reproduces the fault on e72164c, with #335, #571, #576 and #575 merged.

Two questions

1. The mock's quota is a record count, so a batch that does not fit needs a rule for which records to reject. I order the rejections by encoded record size. That is the smallest change that gives a test a large parent that does not fit next to a small child that would fit. A byte count for quota is closer to real CloudKit. I will change it if you prefer that.
2. The mock cannot drive the retry path that Always enqueue pending record changes when preparing batches #576 added, so I left that path untested. sendPendingRecordZoneChanges reports an issue and returns unless pendingRecordZoneChanges is not empty, or hasPendingUntrackedChanges is true. Persisted PendingRecordZoneChange rows satisfy neither check, and Always enqueue pending record changes when preparing batches #576 enqueues them later, inside batch preparation. Did I miss a way to drive that path from a test?